[Observability AI Assistant] Add alert status management to AI Assistant connector by arturoliduena · Pull Request #203729 · elastic/kibana

arturoliduena · 2024-12-11T09:24:17Z

Summary

An Observability AI Assistant connector is available to be set as action for Observability rules. When an alert is triggered, a conversation with the AI assistant will be created sending the initial prompt set by the user in the rule action. The conversation is then stored and can be retrieved from the AI Assistant interface. the action is triggered on any status change of the alert (active, recovered, untracked), creating a new conversation for each of them using the same initial prompt which may not be suitable for the 3 cases.

Improvement
The user is able to choose in when the action should be run (active, recovered, untracked, all),. That would allow the user to specify more than one AI Assistant action, with a different and more suitable prompt in each case.

Screen.Recording.2025-01-21.at.11.59.13.mov

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
Documentation was added for features that require explanation or tutorials
Unit or functional tests were updated or added to match the most common scenarios
If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
Flaky Test Runner was used on any tests changed
The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

elasticmachine · 2024-12-11T09:24:20Z

Pinging @elastic/obs-ai-assistant (Team:Obs AI Assistant)

github-actions · 2024-12-11T09:24:33Z

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

/oblt-deploy : Deploy a Kibana instance using the Observability test environments.
run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

…fix'

…apping'

sorenlouv · 2025-01-21T16:19:03Z

Can you add screenshots to show the ui changes?

arturoliduena · 2025-01-22T08:54:24Z

@sorenlouv

The remove button removes the last prompt. I decided not to include a delete button for each prompt. You can add up to 3 prompts (number of statuses), and there must always be at least one prompt.

Screen.Recording.2025-01-21.at.11.59.13.mov

…lert-status-change

neptunian · 2025-01-24T19:31:18Z

Hey Arturo, I seem to be stuck in the validation

…or handling

…apping'

arturoliduena · 2025-01-27T10:11:06Z

Hey Arturo, I seem to be stuck in the validation

@neptunian fixed it, turns out it was a backward compatibility issue.

neptunian · 2025-01-27T15:55:37Z

One thing I notice in your video that does not happen on main or other connectors, is it now takes some time to load the user's connector and before it does it's considered an error so the "Connector" input flashes red. Any way to avoid this?

.
Do you know of any reason why the rule's message template does not exist for our connector? I think all the other connector's use that rule's message template. We could address this in a followup. It would also avoid the issue of it always being red with an error before the user has even entered anything

sorenlouv · 2025-02-03T12:29:48Z

+    recovered: [...(params.alerts?.recovered || [])],
+  };
+
+  if (ALERT_STATUSES.some((status) => prompt.statuses.includes(status))) {


Why do you need to iterate through ALERT_STATUSES? Won't prompt.statuses always be AlertStatus[] (whatever that type is called)? Could this simply be a check on whether it's empty?

Suggested change

if (ALERT_STATUSES.some((status) => prompt.statuses.includes(status))) {

if (prompt.statuses.length > 0) {

sorenlouv · 2025-02-03T12:30:37Z

+
+  if (ALERT_STATUSES.some((status) => prompt.statuses.includes(status))) {
+    alerts.new = alerts.new.filter((alert) =>
+      prompt.statuses.includes(get(alert, 'kibana.alert.status'))


Not a huge fan of mutating like this. It often leads to bugs down the road.

…lert-status-change

elasticmachine · 2025-02-09T10:32:39Z

💚 Build Succeeded

Buildkite Build
Commit: a53991d
Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-203729-a53991d844ec

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`observabilityAIAssistantApp`	513	526	+13

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`observabilityAIAssistantApp`	298.8KB	300.8KB	+2.0KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`observabilityAIAssistantApp`	14.9KB	15.3KB	+447.0B

History

💔 Build #272226 failed c06d00a
💚 Build #271396 succeeded 447c8b0
💚 Build #271235 succeeded 7ef1784
💚 Build #270883 succeeded 2fca1a8
💚 Build #270378 succeeded e1428a6

kibanamachine · 2025-02-10T12:31:26Z

Starting backport for target branches: 8.x, 9.0

https://github.com/elastic/kibana/actions/runs/13240901596

kibanamachine · 2025-02-10T12:37:30Z

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts You might need to backport the following PRs to 8.x: - [Observability AI Assistant] rule connector - handle multiple prompt (#209221)
❌	9.0	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 203729